woolypiansfandomcom-20200215-history
Git Workflow and Steps to Follow
= Workflow = The workflow I suggest is fairly straight forward and essentially boils down to "Make changes -> make sure they work with other peoples changes -> publish". I've written down the steps I suggest following below and will elaborate on some of them. Steps to Follow for Non-Programmers # Create a new feature branch from the develop branch # Make changes # Commit changes # Pull any possible change from origin/develop (Remote Repository) ## If conflict arises, resolve it ## If your changes somehow break the build or the project is not how you wanted it to be, return to step 2 # When your feature is ready to be shared, checkout the develop branch # Merge your feature branch into the develop branch # Push Step 1 suggests creating a new branch, because the git way to do things is to do everything in branches. If however you're not comfortable with branching just yet you may skip this step and work directly in the develop branch. Step 3 involves a bit more than simply committing changes. Whenever you have changes that you wish to commit, you must first add / stage the files that should be included in the commit. Be picky about which files you add, and only add the necessary ones. .Meta files are necessary. When committing you must also enter a commit message. This should be a clear indication of the changes introduced in the commit. Pulling changes will hopefully merge automatically, but in some cases that is not possible and a conflict will arise. In this case what you need to do is decide whether to use the changes your commit introduces, the ones available on the remote repo, or merging it manually. Merging files manually shouldn't be too difficult, and a lot of merge tools exist to assist in this, and SourceTree even comes with its own diff tool. If you skipped step 1, you can skip step 5 and 6 as well but if not then you should merge your feature branch into the develop branch before pushing. Simplified Workflow for Non-Programmers # Make changes # Commit changes # Pull any possible change from origin/develop (Remote Repository) ## If conflict arises, resolve it ## If your changes somehow break the build, or the project is not how you wanted it to be, return to step 1 # Push Workflow For Programmers The workflow is a bit different because the programmers will be reviewing each others change before it is actually merged into the develop branch. This will be done using pull requests. # Create a new feature branch from the develop branch # Make changes # Commit changes # Pull any possible change from origin/develop (Remote Repository) ## If conflict arises, resolve it ## If your changes somehow break the build or the project is not how you wanted it to be, return to step 2 # When your feature is ready to be shared push your feature branch to origin # Go to BitBucket.org and create a pull request = Branching = Creating a new branch is easy and should be done whenever you start working on something new. In SourceTree you simply checkout the branch that you wish to branch from, then click branch in the top menu. Give it a descriptive name so that you can easily tell which feature the branch is for. Creating a new branch is shown in the image below.